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© Event architecture for system management in an operating system. 
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© An event system is provided within an object-oriented environment. The event system informs users and 
system functions of events within the system. Events may be modeled as objects that are visible within the 
global namespace. These objects include event source objects and event sink objects. Event source objects 
generate event reports and event sink objects are the objects that receive reports. Special objects may be 
incorporated in the system to direct event reports from an event source object to an event sink object. 
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report r'rom the event source object. As part of the registration, an instance of a function \n an interface to 
be called by the event report as received by the event sink object is specified. 

Brier" Description of the Drawings 

5 

Figure 1 'S a block diagram of a data processing system that is suitable for practicing a preferred 
embodiment of the present invention. 

Figure 2A is a block diagram illustrating an instance of the preferred embodiment m which a single 
event report is sent from a single event source to a single event sink. 
'0 Figure 2B is a block diagram illustrating an instance of the preferred embodiment in which a single 
event report is sent from a single event source to multiple event sinks. 

Figure 2C is a block diagram illustrating an instance of the preferred embodiment m whicn multiple 
event sources send multiple event reports to a single event sink. 

Figure 2D is a block diagram illustrating an instance of the preferred embodiment in which a single 
?5 event source sends multiple event reports to multiple event sinks. 

Figure 3 is a diagram of the run time data structures used for interfaces by the preferred embodiment 
to the present invention. 

Figure 4 is a diagram of objects that play a role in the preferred embodiment of the present invention to 
register an event sink object with an event source object to receive event reports. 
20 Figure 5 is a flowchart illustrating the steps performed by the preferred embodiment to register an event 
sink object with an event source object to receive event reports. 

Figure 6 is a flowchart illustrating steps performed by the preferred embodiment of the present 
invention in generating and processing event reports. 

Figure 7 is a block diagram of a preferred embodiment of the present invention when a distributor 
25 object is employed. 

Figure 8 is a block diagram illustrating propagation of an event rePort from a first distributor object :o a 
second distributor object in accordance with a preferred embodiment of the present invention. 

Detailed Description of the Invention 

JO 

A preferred embodiment of the present invention provides an event system architecture for generating 
system management events. The architecture is designed to be easily used and to require minimal 
overhead. The system management events notify processes of certain states. 

Figure 1 shows an illustrative data processing system 10 for practicing a preferred embodiment of the 

55 present invention. Those skilled in the art will appreciate that other types of data processing systems may 
be used for practicing the present invention. The data processing system 10 includes a central processing 
unit (CPU) 12 that oversees activities of the system. The CPU 12 communicates with a memory 14. a 
keyboard 16, a video display 18, a printer 19 and a mouse 24. The memory 14 holds an object-oriented 
operating system 20 that includes an event system 22. Although the operating system 20 of the preferred 

-io embodiment is an object-oriented operating system, those skilled in the art will appreciate that the present 
invention is not limited to such an object-oriented environment. The keyboard 16 and mouse 24 are 
conventional input devices, and the video display 18 and printer 19 are conventional output devices. 

The event system 22 is responsible for overseeing the generation and transmission of event reports that 
report the occurrence of particular events in the system 10. An "event," in this context, is an asyn- 

-!5 chronously arising condition relative to a destination process that wishes to be informed of the event. The 
process in which the condition arises is the "event source." whereas the process to which the event is 
reported is the "event sink." An "event report" reports an event and is transmitted from the event source to 
the event sink (as will be described in more detail below). The event source and event sink are objects that 
are visible in a distributed namespace of the system 10. The distributed namespace is a logical organization 

so of the "names of objects" (described in more detail below) that are stored in the system 10. 

The preferred embodiment of the present invention allows application programs run on the system 10 
(Figure 1) to generate and receive information about external events without possessing knowledge about 
the events or the sources of the events. It provides a means for an event sink 27 (Figure 2A) to register with 
an event source 23 to receive an event report 25. The event sink 27 may then invoke an event handler to 

55 respond to the occurrence of the event. The design of the preferred embodiment leverages the distributed 
namespace of the system to provide places for event sinks- to register. The preferred embodiment aiso 
provides a means to send the event report from the event source to the event sink. 
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It should be noted that an event report 25 need not be generated from a single event source 23 fcv 
transm.ss.on to a single event sink 27 as shown in Figure 2A. In many instances, a angle event repor, 25 
may be sent from a single event source 23 to multiple event Sinks 27. 27' or 27". as shown in Figure 28 

nZlTr? S 7?, 6Vem S ' nk 27 rSCeive diff6rem evem reports 25 and 25 ' *<™ Afferent even, 
™ A" , reSpeCtively - as shown ,n R 9ure 2C. Still further, a single event source 23 may 
generate different even, reports 25 and 25' (Figure 2D) that are destined to different event smks 27 and 27 
respectively. In general, an event source may generate multiple or single even, reports that are deemed to 
one or many event smks. 

In order to understand how the preferred embodiment of the present invention operates, it is necessary 
to hrst understand certain programming concepts that are employed therein. One of the concepts emptoyed 
by the preferred embodiment of the present invention is the notion of an "object." An "object" ,s an Entity 

Set upw thedaT binat '° n ° f ^ th ' n9S: d3ta th3t SPedfieS a " imemal State °' the ° D|ect and functlons tha ' 

svstlmpn 8 !^ °' the Pr6Sent ' nVenti0n ' S d6Si9ned far use in the object-oriented operating 

™T , Q T 1 6 ° Perat,nQ SySt6m 20 Supp0r,s an ^erlying object model. As such, many 

,nTs 27 Z 1h , S r tem , are m °c deled 33 0bieC,S ' F ° r eXamP ' e - eV6nt S0UrCes 23 < Fi 9 ure 2a > ™ event 
win h P h! TT aS ° b,eCtS - Event rep0rtS may be objects havin 9 Properties. Other objects of interest 

be described m more detail below. All of these objects are visible in the distributed namespace and 
thus their properties are easily accessible. 

A closely related concept is the concept of an "interface." An "interface" is a group of semantical 

ISSJJT; 8 ^ ° r9an,Zed ' nt0 3 Unit <the name be ' n9 the ' dent '- of - erS 

TntZ ;■ \T ? 9 00 inStantiation (' e - a de,ini "° n of an interface does not include code for 

mp ementmg , he functions tha, are ident.fied in the in.erface): ralher, interfaces specify a set of Signatures 
for unctions. Instantiation" refers to the process of creating m-memory structures that reoresent an obiect 
so that operations can be invoked on the object. When an object "supports" an in.erface the ob,ec, 
provides code for the functions specified by the interface. Thus, the object tha, supports the interface s 
responsible for providing the code for implementing the functions of the interface. The code that is provided 
must comply w.th the signatures of the functions specified by the interface (i.e.. the code musf have , e 
S ame parameters and functionality as are specified in the interface). Accordingly, an interface may b P 
viewed as a standard with which objects must comply. 

Interfaces support extensiblity by allowing new interfaces to be developed in a fashion that does not 
a fee existing applications. Interfaces are also consistent with the client server model tha. ,s adopted by he 
operating system 20. In particular, interfaces are used to provide services to a client object. A server object 
s defined to support the interface, and the interface defines the functions tha. provide the services of he 
server object. For instance, the even, source 23 (Figure 2a) may be viewed as a server objec nd the 
event sink 27 may be viewed as a client object. 

The run time manifestation of an interface instance is a data structure that provides access to the 
functions defined or the interface. Interface instances are referenced by clients us.ng pointers As shown n 
Figure 3, an . interface pointer 28 points ,o an entry in the objec, da.a 29 of the objec, ,ha, support the 
instance of he .n.erface. In particular, the interface pointer points to an entry in .he object d« t at 
olds a pointer to a virtual .able (i.e.. a vtable, such as commonly used in c* ♦ programming,. The vta e 
31 holds a senes of pointers ,o instances of functions 33 that are supported by the object Pointers ,o the 
functions included ,n the interface are among those provided in the viable 31 

Each obiec, m the distributed namespace 28. by definition, must support the lUnknow, 
objects support interfaces that inherit the (Unknown interface). The lUnknown interface 



•s ahiJJ « J "\ J d ' S,nbuted names P^e 28. by definition, must support the lUnknown interface (, e all 
-s objects support interfaces tha, inherit the lUnknown interface). The lUnknown interface is a standardized 
interface provided by the operating system ,ha, includes a function. Query.nterface,,, for 
an object supports a particular in.erface. The Query,n,erface„ function returns a pointer ,o an instance o an 
:S' S Spe f ed . in < he para ™^ °' the function. In genera,, whenever a function is ca ed ,ha, 
par, of an instance of an interface, the QuerylnterfaceO function must first be called 

50 hJl" imer, l Ce P °'T SUCh aS r6tUmed by ,he QuerylnterfaceO function, may serve as a connection 
between an object and a client. „ i S difficult, however, for external entities to discover in.erface pointers ha" 
fn object has dispensed, and it is difficult for external entities to discover in.erface poin.ers .o other ob ec 
objects that an objec, holds. To overcome .hese difficulties, the operating system 20 P ov^des soSare 
connectors. Software connectors are standardized interfaces for connecting objects ^g e h e r and ^ 

oh V Sf - r r n9 ,K "? 3CeS °' ^ ° bieCt ,h3t are accessible by 9vents - 9eneral. a coSion between 
objects ,n the preferred embodiment of the present invention is realized by passing an interface oomter 
from one obiec, diredy ,o another object in order ,o establish a meaningful cowctTllZen he 
object,. Both objects must share at least one connecting interface. Software connector, are u « ed n he 
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preferred embodiment of ;he present invention to establish connections between an event source and an 
event sink. This process will be described below as "registration". 

Before discussing how an event sink registers with an event source to receive event reports, it is helprui 
xo consider how events are defined relative to the objects that may generate them. In general, an object 
specifies an event set of events that it is capable of generating. The event set is part of the object's 
cefinmon and is described m type information provided for the object. The type information may be stored 
in a storage structure that is separate from the object. The type information specifies which events are 
provided m the objects of that set. Consider as an example as object that supports an event set known as 
the DiskEventSet. This event set is identified as follows: 



DiskS pace Low( DiskS pace Event psEvent); 
DiskF uiKDiskSpaceEvenc psEveat); 
Di5k£rror(DiskErTorEveni psEvent) 



DiskSpaceEvent is a property set that may be defined as follows: 



propset DiskSpaceEvent : public Disk Event 
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LARGE_LNTEGER 
LARGE INTEGER 



} 



{ 



} 



ULONG 
WCHAR 



propset ISystemEvent 

{ 

mandatory: 

SYSTIME 

UUTD 

ULONG 

UUTD 

ULONG 

ULONG 

} 



DiskSpaccAvaihble; 
TotalDiskSpace; 



propset DiskEvertt : public ISystemEvent 



UTVoiumeED; 
pwzVolumeName; 



timeEventCreationTime; 

uuidCIassId; 

sevSeverity; 

uindCategory£D; 

ulEvemCode; 

ulHopCount: 
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Before discussing the registration process in more detail, it is useful to first introduce the objects which 
play a role within this registration process. Figure 4 is a diagram illustrating an example situation wherein 
the objects that play a role in registration are used. Figure 4 illustrates an instance wherein a printer 46 
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above, an event source object 42 is an obi P rt JLL 5 6wed by the user As discussed 

supports .he 'Connecbo^^ -en, source ob.ec, 42 

connector ,n a container ob,ect. An event so^ ,!,^^^ ^^ ^ * 

registered even, s.nks for an event source ob,ert Thl f ? ' S ° b,ect that ma,nta,n s a list of 

muiti-cas.ing of event reports , each ,2', T™ **** ^ 5 ° ' S reSP ° nS,b,e for !he 
source holder ob ie c 50 include 0 fT^ sZ ^ SXamPle °' Rgure 4 ' ,he »™« 

pnnter 46. An event source .nMe^'oZ ^ ^ ^ I '^'^ '° ^ 8vent reports f ™ 
an interface pointer to an even, s, nk o Jec , and ho Ids L ^ ^ * 3 C ° nneCti ° n ° b,eC ' ^ !t 
smk object, in Figure 4. the event ^Z^tZT^^ ** COnneCt '° n t0 ™ m 
(i-e.. ,t holds one entry from the register of evS Z o^eCs, ^ 8 S ' n9 ' e 9V9m 

r^sr^ ^rrrer r:?:?::v e9is,ra,ion of an - ent -* — » - ■« 

connection tool is as follows: COde f ° r "Renting these steps ,n a separate 

pconS.nk- > Quen-fmcrfacedlDJSysteaEveatSink. ApesokSink); 
//Setup the source side of tie registration 

pSoarc S .>Qu er vI nt e r fac,(IID_[CoanectionConta 1 ner. & pic C Sourc e )- 
piccSoarcs - > VewCnnneaion. IID.FEventSet, JkpconSource); 

.•' 'Actually perform tie connection. 

pconiour«.>Conae«( pesakSinx, IIDJSystemEveatSink. CONNECTFLAGS_PERSIST) 

Initially, a pointer to the event sink ohiprt /; 0 «„c- i « • »-• 
Next, a pcnter to the even, source ob ec S ob t ined (st 62^ I'T*™ ^ 56 ^ 5 »' 
'unction ,s cal.ed in the second instruction in Z ITe rS/' 9 " 1 Specifical| V^ Querylnterfacef) 
source object 42 (pointed to by "pSource" n Sure ^T, '° determ ' ne whether the even, 

stores ,he resulting poin.er ,o the SS^ cThSZISSZ , 'f 0 ™^**™ ^ace and 
to the event source object (i.e.. a pointer to a tn that E.^"* " PiCCS ° urCe " A 
acquired (step 64 in Figure 5). The call to the NeZn! ! connection to the object) is then 

tainer interface of the even, source cb^i^J^^T^rT^ ^ "* IConn ^,ionCon- 

The connect function is then raJn \L . 6 connector in "PConSource". 

aiven above, the connS ZS^Z £ 7? " ^ 5> »» C ° de 

40 is caned ,o connect ,he event sin k obJ«'^ E Z?l;roS^ , 2 ,0,,8d * 6Vem ^ ^ 

- err: ™ — - - - 

integer data and floating point data Zperl set Ta, C L *** type ' character data 

loaded ,n,o the variants. This array of varies TJ^LlZ^T ° rmati ° n ^i^ 9 3(1 event ™ 
encapsulated into an even, report objej hat TZrZ „ ^ ^ Eacn e^' report may be 
namespace. One of the properties Ld w, , the IZ ITXT?" Tn ^ ^ the dis, " b ^ d 
to manufacture an event report object V 3 Cl3SS ' ° Tne class 10 m ay be utilized 

CeclTev^ — ^ ^ an even, source 

even, source holder filters the output of the evem renn I 9 6Vem S ° UrCe ° bject < ste P 7 °> The 

report to the regis,ered even, „,* ^ ,e 2) ^ ^31 ^ ' herein and SendS the 

handler ,o respond to the event report (steo 74, tZ . I ^ ' ep0rt and cal1 * a " even, 

handler may generate activity in £^£1%™^.*™ 6XeCutes <•*> ^ The even 
-e,y of o P ,ions as ,o ho. ,o respond ,o ^Z^ZZ^ ^ * ^ 
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A system may also include special objects, known as "distributor objects." A distributor ooject -s an 

object which exists in the global namespace to route event reports to event sinks. Figure 7 depicts a 

distributor obiect 32 that receives event reports from event sources 80, 80' and 80". The distributor ooject 

32 provides both event source and event sink functionalities. The distributor object 82 routes the event 
5 reports received from the event sources 80. 80' ana 80" to event sinks 84. 84' and 84". Distributor objects 

32 are useful m grouping event sources ana sinks as sets. For example, a distributor may be used to 

represent all acmrnistrators on a given domain. 

A distributor object may also be configured to propagate event reports to other aistnbutor objects. 

Figure 3 shows an example of a situation m which a distributor object »88 receives an event report 92 from 
:o an event source 36 and propagates the event report to a second distributor object 90. The Difference 

between this type of prooagation and the propagation that occurs with normal registration is that filtering 

information 94 stored on the second distributor object 90 is forwarded to the first distributor object 38. This 

filtering information specifies which type of event report the distributor object 90 is interested m obtaining. 

The first distributor object 88 filters the incoming event reports 92 to determine whether the second 
;s distributor object 90 wishes to receive the event report. The filtering information 94 is stored on the second 

distributor object m such a way that it is available to any distributor object that is registered to propagate 

event reports to the second distributor object. 

The operating system 20 provides a number of dispatch interfaces. A dispatch interface, in this context. 

is as defined in the Microsoft Object Linking ana Embedding (OLE) 2.0 protocol, established by Microsoft 
20 Corporation of Redmond. Washington. Dispatch interfaces allow access to methods, properties and cata 

members of objects whose interface is not known. Each dispatch interface has functions that allow a caller 

to retrieve and send property values. The event distributor objects have the ability to call any dispatchabte 

interface. Parameter information is stored with the registration information for the event sink object. 

Prcoerties are set on the software connector to the event sink in the event source such that each 
25 registration can have us own interface to be called. As an example, this capability allows a system event to 

trigger the printing of a word processing document through the call to the unique interface associated with 

the registration of an event sink. 

It should be appreciated that registrations may be maintained over a period of time. Registrations are 

not strictly a one-time phenomena. The registration need not be deleted after a single event occurs. 
30 Maintaining the registration is helpful in performing functions such as logging. Logging involves recorcmg 

event reports in a file to create a log. The log may be later viewed to provide a historical record or activity 

of a part of the system. 

A preferred embodiment of the present invention enhances the ability of system administration 
functions to become aware of relevant events within the system.. This capability stems, in large part, from 
J5 segregating the occurrence of an event from the response to the event. The preferred embodiment also 
facilitates segregation by event type so that the system administrator may be aware of the different types of 
events and respond accordingly. 

Since event reports are objects in the global namespace, both users and system components have 
access to the event reports. The event reports include important state information that may be used by 
-o users and system components alike. The user has the ability to discover what events a program is capable 
of generating and can register to receive notice of any such events. 

While the present invention has been described with reference to a preferred embodiment thereof, 
those skilled in the art will appreciate that various changes in form and scope may be maae without 
departing from the present invention as defined in the appended claims. For instance, the present invention 
J5 need not be practiced in a single processor system like that shown in Figure 1 ; rather the present invention 
may also be practiced in a distributed system. 

Claims 

so 1. In a data processing system having memory means and processing means, a method comprising the 
steps of: 

storing a global namespace of objects in the memory means; 

providing event source objects for generating event reports in response to events at the event 
source objects, an event sink object for receiving event reports and a distributor object for distributing 
55 event reports from the event source objects to the event sink object: 
triggering an event at one of the event source objects; 

generating an event report at the event source object where the event was triggered; 
forwarding the event report to the distributor object; and 

7 
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forwarding the event report from the distributor object to the event sink object to inform the event 
sink object of the triggered event. 

2. The method as recited in claim i. further comprising the step of registering the event sink with the 
5 distributor object to receive the event report. 

3. The method as recited in claim 1. further comprising the step of providing at feast one additional event 
sink object that is visible in the globai namespace. 

ro 4. The method as recited in claim 3, further comprising the step of registering the additional event sink 
object with the distributor object to receive the event report. 

5. The method as recited in claim 1. further comprising the step of providing the distributor object with a 
filter that is examined to determine where the event report should be forwarded. 

6. The method of claim 1 wherein the event report is an object that is visible in the global namespace. 

7. In a distributed system having processors running an object-oriented operating system, a method 
comprising the steps of: 

20 providing a plurality of event source objects: 

providing a plurality of event sink objects; 
providing a distributor object: 

registering the event sink objects w)th the distributor object to be informed of events at the event 
source objects: 

25 generating event reports at the event source objects in response to events at the event source 

objects: 

forwarding the event reports to the distributor object: and 

determining which event sink objects should receive the event reports and forwarding the event 
reports to the determined event sink objects. 

10 

8. The method of claim 7 wherein the event report is an object that is visible in the global namespace. 

9. In a data processing system having a storage device, a method comprising the steps of: 

storing an event source object in the storage device, said event source object generating events 
35 and event reports that report the events: 

storing event sink objects in the storage device; 

storing an event source holder object .n the storage device, said event source holder object 
maintaining a register of registrations by event sink objects that are registered to receive an event 
report upon occurrence of an event at the event source object; 
40 triggering an event at the event source object; and 

sending event reports to event sink objects that are registered with the event source holder object. 

10. The method recited in claim 9, further comprising the step of registering an event sink object with the 
event source holder to receive an event report after an event is triggered at the event source 

-5 

11. The method recited in claim 9 wherein the step of sending event reports further comprises the step of 
sending a data structure holding property information about the triggered event to event sink objects 
that are registered with the event source holder object. 

50 12. The method recited in claim 9, further comprising the step of storing each registration in an object in 
the storage device. 

13. In a data processing system having a storage device, a method comprising the steps of: 

storing an event source object in the storage device, said event source object being capable of 
55 raising a set of events: and 

storing type information about the event source object in the storage device, said type information 
specifying the set of events that the event source object may raise. 
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4. In a data processing system having memory means and processing means, a method comprising the 
steps of: 

providing at least one event source object m the memory means for generating an event report :n 
response to an event at the event source object: 

providing a first distributor object and a second distributor object in the memory means, said first 
distributor object serving to distribute the event report when generated by the event source object to 
•he second distributor object: 

triggering the event at the event source object: 

generating an event report at the event source object: 

forwarding the event report to the first distributor object: 

providing filtering information from the second distributor object to the first distributor object, said 
filtering information specifying a type of event report that the second distributor object wishes to 
receive: and 

where the filtering information indicates that the second distributor object wishes to receive the 
event report, forwarding the event report from the first distributor object to the second distributor object. 

5. In a data processing system having processing means and memory means, a method comprising the 
steps of: 

providing an event source object for generating an event report in response to an event and an 
event sink object for receiving the event report: and 

registering the event sink object to receive the event report from the event source object, wherein 
as part of the registration specifying an instance of a function in an interface to be cailed when the 
event report is received by the event sink object. 

6. The method of claim 15. further comprising the steps of: 

triggering the event at the event source object: 

generating the event report at the event source object and forwarding the event report to :he event 
sink object; and 

tn response to receiving the event report at the event sink object, invoking the function of -the 
instance of the interface specified in the registration. 
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